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Abstract 


Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical 
specification defines an optional Application-Layer Forward Error 
Correction (AL-FEC) protocol to protect the streaming media 
transported using RIP. The DVB-IPTV AL-FEC protocol uses two layers 
for FEC protection. The first (base) layer is based on the 1-D 
interleaved parity code. The second (enhancement) layer is based on 
the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC 
protocol offers good protection against both bursty and random packet 
losses at a cost of decent complexity. This document describes how 
one can implement the DVB-IPTV AL-FEC protocol by using the 1-D 
interleaved parity code and Raptor code that have already been 
specified in separate documents. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6683. 
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1. Introduction 


In 2007, the IP Infrastructure (IPI) Technical Module (TM) of the 
Digital Video Broadcasting (DVB) consortium published a technical 
specification [ETSI-TS-102-034v1.3.1] through the European 
Telecommunications Standards Institute (ETSI). 
[ETSI-TS-102-034v1.3.1] covers several areas related to the 
transmission of MPEG2 transport stream-based services over IP 
networks. 


Annex E of [ETSI-TS-102-034v1.3.1] defines an optional protocol for 
Application-Layer Forward Error Correction (AL-FEC) to protect the 
streaming media for DVB-IP services transported using RTP [RFC3550]. 
In 2009, DVB updated the specification in a new revision that is 
available as [ETSI-TS-102-034v1.4.1]. Among others, some updates and 
modifications to the AL-FEC protocol have been made. This document 
describes how one can implement the DVB-IPTV AL-FEC protocol by using 
the 1-D interleaved parity code [RFC6015] and Raptor code 
specifications [RFC6681] [RFC6682]. 
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The DVB-IPTV AL-FEC protocol uses two layers for protection: a base 
layer that is produced by the 1-D interleaved parity code (also 
simply referred to as "parity code" in the remainder of this 
document), and an enhancement layer that is produced by the Raptor 
code. Whenever a receiver supports the DVB-IPTV AL-FEC protocol, the 
decoding support for the base-layer FEC is mandatory while the 
decoding support for the enhancement-layer FEC is optional. Both the 
interleaved parity code and the Raptor code are systematic FEC codes, 
meaning that source packets are not modified in any way during the 
FEC encoding process. 


The DVB-IPTV AL-FEC protocol considers protection of single-sequence 
source RTP flows only. In the AL-FEC protocol, the source stream can 
only be an MPEG-2 transport stream. The FEC data at each layer are 
generated based on some configuration information, which also 
determines the exact associations and relationships between the 
source and repair packets. This document shows how this 
configuration may be communicated out-of-band in the Session 
Description Protocol (SDP) [RFC4566]. 


In DVB-IPTV AL-FEC, the source packets are carried in the source RIP 
stream and the generated FEC repair packets at each layer are carried 
in separate streams. At the receiver side, if all of the source 
packets are successfully received, there is no need for FEC recovery 
and the repair packets may be discarded. However, if there are 
missing source packets, the repair packets can be used to recover the 
missing information. 


The block diagram of the encoder side for the systematic DVB-IPTV 
AL-FEC protection is described in Figure 1. Here, the source packets 
are fed into the parity encoder to produce the parity repair packets. 
The source packets may also be fed to the Raptor encoder to produce 
the Raptor repair packets. Source packets as well as the repair 
packets are then sent to the receiver(s) over an IP network. 
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4 + 
+--+ +--+ +--+ +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 
+--+ +--+ +--+ +--+ |FEC Protection | +--+ +--+ +--+ +--+ 
4 + 
| Parity | -> +==+ +==+ +==+ 
| Encoder | +==+ +==+ +==+ 
4 + 
| Raptor | -> 07H +774 
| Encoder | +774 +477 
4 + 


Source Packet: +--+ 
+--+ 


Base-layer Repair Packet: +==+ 
+==+ 


Enhancement-layer Repair Packet: + 


Figure 1: Block Diagram for the DVB-IPTV AL-FEC Encoder 


The block diagram of the decoder side for the systematic DVB-IPTV 
AL-FEC protection is described in Figure 2. This is a minimum 
performance decoder since the receiver only supports decoding the 
base-layer repair packets. If there is a loss among the source 
packets, the parity decoder attempts to recover the missing source 
packets by using the base-layer repair packets. 


4 + 
+--+ X xX +--+ --> | Systematic | -> +--+ +--+ +--+ +--+ 
+--+ +--+ |FEC Protection| +--+ +--+ +--+ +--+ 
4 + 
4==+ +4==+ +==+ --> Parity 
+==+ +==+ +4==+ Decoder 
4 + 


Lost Packet: X 


Figure 2: Block Diagram for the DVB-IPTV AL-FEC Minimum Performance 
Decoder 


On the other hand, if the receiver supports decoding both the base- 
layer and enhancement-layer repair packets, a combined (hybrid) 
decoding approach is employed to improve the recovery rate of the 
lost packets. In this case, the decoder is called an enhanced 
decoder. Section 2.3 outlines the procedures for hybrid decoding. 
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4 + 
+--+ X x x --> | Systematic | -> +--+ +--+ +--+ +--+ 
+--+ |FEC Protection| +--+ +--+ +--+ +--+ 
4 + 
+==+ 4==+ +4==+ --> | Parity | 
+==+ +==+ +==+ | Decoder | 
4 + 
44 +T => | Raptor | 
+774 +7 | Decoder | 
4 + 


Lost Packet: X 
Figure 3: Block Diagram for the DVB-IPTV AL-FEC Enhanced Decoder 
2. DVB-IPTV AL-FEC Specification 


The DVB-IPTV AL-FEC protocol comprises two layers of FEC protection: 
1-D interleaved parity FEC for the base layer and Raptor FEC for the 
enhancement layer. The performance of these FEC codes has been 
examined in detail in [DVB-All5]. 


2.1. Base-Layer FEC 


The 1-D interleaved parity FEC uses the exclusive OR (XOR) operation 
to generate the repair symbols. In a group of D x L source packets, 
the XOR operation is applied to each group of D source packets whose 
sequence numbers are L apart from each other to generate a total of L 
repair packets. Due to interleaving, this FEC is effective against 
bursty packet losses up to burst sizes of length L. 


The DVB-IPTV AL-FEC protocol requires that the D x L block of the 
source packets protected by the 1-D interleaved FEC code be wholly 
contained within a single source block of the Raptor code, if both 
FEC layers are used. 


Originally, the DVB-IPTV AL-FEC protocol had adopted the 1-D 
interleaved FEC payload format from [SMPTE2022-1] in 
[ETSI-TS-102-034v1.3.1]. However, some incompatibilities with RTP 
[RFC3550] have been discovered in this specification. These issues 
have all been addressed in [RFC6015] (for details, refer to Section 1 
of [RFC6015]). Some of the changes required by [RFC6015] are, 
however, not backward compatible with the existing implementations 
that were based on [SMPTE2022-1]. 


In a recent liaison statement from the IETF AVT WG to DVB TM-IPI, it 
has been recommended that DVB TM-IPI define a new RTP profile for the 
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AL-FEC protocol since in the new profile, several of the issues could 
easily be addressed without jeopardizing the compliance to RTP 
[RFC3550]. 


At the writing of this document, it was not clear whether or not a 

new RTP profile would be defined for the AL-FEC protocol. DVB TM-IPI 
attempted to address some of the issues in the updated specification 
[ETSI-TS-102-034v1.4.1]; however, there are still outstanding issues. 


The following is a list of the exceptions that need to be considered 
by an implementation adopting [RFC6015] to be compliant with the DVB- 
IPTV AL-FEC protocol as specified in [ETSI-TS-102-034v1.4.1]. 


o SSRC (synchronization source) 
The DVB-IPTV AL-FEC protocol requires that the SSRC fields of the 
FEC packets be set to zero. 


This requirement conflicts with RTP [RFC3550]. Unless signaled 
otherwise, RTP uses random SSRC values with collision detection. 
An explicit SSRC signaling mechanism is currently defined in 
[RFC5576] and can be used for this purpose. 


o CSRC (contributing source) 
The DVB-IPTV AL-FEC protocol does not support the protection of 
the CSRC entries in the source packets. Thus, in an 
implementation compliant to DVB-IPTV AL-FEC protocol, the source 
stream must not have any CSRC entries in its packets, and 
subsequently the CC fields of the source RTP packets will be zero. 


Note that if there are no RTP mixers used in a system running the 
DVB-IPTV AL-FEC protocol, the CC field of the source RTP packets 
will be zero and this is no longer an issue. Thus, if defined, 
the new RTP profile for the DVB-IPTV AL-FEC protocol should forbid 
the use of any RIP mixers. 


o Timestamp 
In the DVB-IPTV AL-FEC protocol, the timestamp fields of the FEC 
packets are ignored by the receivers. 


o Payload Type 
The DVB-IPTV AL-FEC protocol sets the PT fields of the FEC packets 
to 96. 


A static payload type assignment for the base-layer FEC packets is 
outside the scope of [RFC6015]. If defined, the new RTP profile 
for the DVB-IPTV AL-FEC protocol may assign 96 as the payload type 
for the base-layer FEC packets. 
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In implementations that are based on [RFC6015] and are willing to be 
compliant with the DVB-IPTV AL-FEC protocol as specified in 
[ETSI-TS-102-034v1.3.1], all these exceptions must be considered as 
well; however, in this case, the sender does not have to select a 
random initial sequence number for the FEC stream as suggested by 
[RFC3550]. 


Note that neither [ETSI-TS-102-034v1.3.1] nor [ETSI-TS-102-034v1.4.1] 
implements the 1-D interleaved parity code as specified in [RFC6015]. 
Thus, the payload format registered in [RFC6015] must not be used by 
the implementations that are compliant with the 
[ETSI-TS-102-034v1.3.1] or [ETSI-TS-102-034v1.4.1] specification. 


2.2. Enhancement-Layer FEC 


The Raptor code is a fountain code where as many encoding symbols as 
needed can be generated by the encoder on-the-fly from source data. 
Due to the fountain property of the Raptor code, multiple enhancement 
layers may also be specified, if needed. 


The details of the Raptor code are provided in [RFC6681]. The FEC 
scheme for the enhancement layer SHALL be the Raptor FEC scheme for a 
Single Sequenced Flow with FEC encoding ID 5. The RTP payload format 
for Raptor FEC is specified in [RFC6682]. 


It is important to note that the DVB-IPTV AL-FEC protocol in the 
latest specification [ETSI-TS-102-034v1.4.1] allows both UDP-only and 
RTP-over-UDP encapsulations for the enhancement-layer FEC stream. 

The initial specification [ETSI-TS-102-034v1.3.1] exclusively permits 
UDP-only encapsulation for the enhancement-layer FEC stream. 


When SDP is used for signaling, the transport protocol identifier 
indicates whether an RTP-over-UDP or UDP-only encapsulation is used. 
In case of any other signaling framework, the differentiation of the 
protocol for the enhancement-layer stream is achieved either 
explicitly through a protocol identifier or implicitly by the version 
number of the DVB IPTV Handbook. If none of the above signaling is 
provided, the receiver shall concur from the packet size of the 
repair packets if RTP-over-UDP or UDP-only encapsulation is used. 


2.3. Hybrid Decoding Procedures 
The receivers that support receiving and decoding both the base- and 
enhancement-layer FEC perform hybrid decoding to improve the repair 


performance. The following steps may be followed to perform hybrid 
decoding: 
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1. Base-layer (Parity) Decoding: In this step, the repair packets 
that are encoded by the parity encoder are processed as usual to 
repair as many missing source packets as possible. 


2. Enhancement-layer (Raptor) Decoding: If there are still missing 
source packets after the first step, the repair packets that are 
Raptor encoded are processed with the source packets already 
received and the source packets that are recovered in the first 
step. 


3. Hybrid Decoding: If there are still missing source packets after 
the second step, the unprocessed base-layer (parity) repair 
packets are converted to a form in which they can be added to the 
Raptor decoding process. With this additional information, 
Raptor decoding may potentially recover any remaining missing 
source packet. 


The procedure that should be followed to benefit from the base-layer 
repair packets in the Raptor decoding process is explained in detail 
in Annex E.5.2 of [ETSI-TS-102-034v1.4.1]. 


3. Session Description Protocol (SDP) Signaling 


This section provides an SDP [RFC4566] example for 
[ETSI-TS-102-034v1.4.1]. The example uses the FEC grouping semantics 
[RFC5956]. 


In the example, we have one source video stream (mid:S1), one FEC 
repair stream (mid:R1) that is produced by the 1-D interleaved parity 
FEC code, as well as another FEC repair stream (mid:R2) that is 
produced by the Raptor FEC code. We form one FEC group with the 
"a=group:FEC-FR S1 R1 R2" line. The source and repair streams are 
sent to the same port on different multicast groups. The source, 
base-layer FEC, and enhancement-layer FEC streams are all 
encapsulated in RTP. 


Due to the exceptions described in Section 2.1, a 
[ETSI-TS-102-034v1.4.1]-compliant implementation must not use the RTP 
payload format defined in [RFC6015]. Instead, it may use the payload 
format that has been registered by DVB TM-IPI for 
[ETSI-TS-102-034v1.3.1]. 
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v=0 

o=ali 1122334455 1122334466 IN IP4 fec.example.com 
s=DVB-IPTV AL-FEC Example 

t=0 0 

a=group:FEC-FR S1 R1 R2 

m=video 30000 RTP/AVP 100 

c=IN IP4 233.252.0.1/127 

a=rtpmap:100 MP2T/90000 

a=mid:S1 

m=application 30000 RTP/AVP 96 

c=IN IP4 233.252.0.2/127 

a=rtpmap:96 vnd.dvb.iptv.alfec-base/90000 
a=mid:R1 

m=application 30000 RTP/AVP 111 

c=IN IP4 233.252.0.3/127 

a=rtpmap:111 vnd.dvb.iptv.alfec-enhancement/90000 
a=mid:R2 


Note that in the example above, the payload type has been chosen as 
96 for the base-layer FEC stream and there is no "a=fmtp:" line to 
specify the format parameters. Due to the lack of the format 
parameters for "vnd.dvb.iptv.alfec-base", it is not possible to learn 
the FEC parameters from the SDP description. 


4. Security Considerations 


This specification adds no new security considerations to the DVB- 
IPTV AL-FEC protocol. 
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